In computer systems having a processor and more than one attached input/output (I/O) device, I/O ports are often used as the interface between the processor and the attached I/O devices. The I/O devices are controlled by a device driver which is implemented in software as a set of subroutines in the processor. In such systems, a mechanism must be provided to coordinate communications through the I/O port between the device driver and the I/O device. Generally, two such coordination methods are known: the polled transmission method and the hardware interrupt method.
In the polled transmission method the processor runs detection cycles to sequentially poll or interrogate the I/O devices through the I/O ports to determine the operational status of the I/O devices. By means of this polling transmission method, the device driver is notified of the readiness of a particular device to send or receive data. The polled transmission method, however, requires the processor to run detection cycles continuously, regardless of the relative activity or inactivity of the attached I/O devices. The Disk Operating System (DOS) currently utilizes the polled transmission method, although it could be written to utilize the hardware interrupt method.
The hardware interrupt method is the mechanism used to coordinate communications between the device driver and attached I/O devices in the IBM.RTM. OS/2.RTM. operating system. In the hardware interrupt method, the processor does not run special processor detection cycles to sequentially poll the I/O devices to determine their operational status. Instead, the I/O devices directly provide programmable interrupt controller hardware with an indication of their operational status, thereby permitting better utilization of the processor to schedule other tasks to run. By means of an interrupt signal, the individual I/O devices notify the programmable interrupt controller that they are ready to send or receive data. The programmable interrupt controller in turn notifies the processor of the interrupt status of an I/O device, and the processor invokes the device driver to service the interrupt request.
The hardware interrupt method, however, is susceptible to potential communications difficulties between the device driver and the attached I/O devices in some computer systems. In particular, a lost hardware interrupt condition between the device driver and an attached I/O device may occur if more than one parallel I/O port adapter shares the same interrupt level. This situation may occur, for example, when multiple parallel ports are implemented on the IBM.RTM. PS/2.RTM. Micro Channel.RTM..
Specifically, each of the I/O ports in these systems includes a read-only device status register for its corresponding attached I/O device which provides an indication of the operational status of the I/O device by containing the status of its hardware interrupts. The register includes an acknowledge bit which is pulsed active by an I/O device when it needs servicing by the device driver, and an interrupt request status bit which is latched active by the acknowledge pulse to indicate to the device driver that an interrupt is pending for that I/O device. A pulsed signal is one which is set active for a period of time and then set inactive. The acknowledge bit is pulsed active, for example, when an I/O device needs to acknowledge accurate transmission of a byte of data sent by the device driver. The device driver typically reads and subsequently clears the interrupt request status bit in the device status register which has been set by the acknowledge pulse and proceeds to send the next byte of data to the I/O device.
Due to the design of the parallel I/O port adapters described above, however, it is possible for the device driver to read and subsequently clear the interrupt request status bit in the device status register for a particular I/O device at the same time as the acknowledge pulse arrives to set the interrupt request status bit for that I/O device. As a result of these coinciding events, the device driver continues to wait for an active interrupt request status bit acknowledging receipt of the previous byte of data from the I/O device, while the I/O device waits for the next byte of data to be sent by the device driver. The problem is exacerbated in a multiple I/O device environment because each I/O port is sequentially polled by an interrupt service routine to monitor the interrupt request status bits for the I/O devices. Thus, the possibility of a device driver reading and subsequently clearing an interrupt request status bit simultaneously with the arrival of a corresponding acknowledge pulse increases with the number of I/O ports in the system.
Device drivers generally are provided with a timeout mechanism incorporated into their logic to terminate transmission of data to an I/O device after waiting a predetermined amount of time without receiving acknowledgement of successful transmission by the I/O device. From a user standpoint, the data transmission request is terminated for no apparent reason, and must be either retried or canceled. It is an object of the present invention, then, to provide a solution to the problem of the lost hardware interrupt occurring between a device driver and an attached I/O device, by improving the means by which hardware interrupts are detected by a device driver.